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(57) ABSTRACT 
Systems, client computing devices, server computing 
devices, and methods are disclosed for accessing medical 
devices, providing remote access to medical devices and/or 
remotely accessing medical devices. In one exemplary 
embodiment, client computing devices utilize protocol com- 
ponents that may be obtained from a server computing 
device via a network to communicate with medical devices 
in a communications protocol supported by the medical 
device. 
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REMOTE MEDICAL DEVICE ACCESS 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to medical 
devices, and more particularly to remote medical device 
access. 

BACKGROUND OF THE INVENTION 

[0002] Patients commonly use medical devices to monitor 
various biological and/or physiological conditions. For 
example, patients with diabetes often utilize a blood glucose 
meter to monitor their blood glucose levels periodically. 
However, medical devices are also used for monitoring 
and/or analyzing biological/physiological parameters or 
conditions such as body fluids or bodily functions (e.g. 
blood, urine, saliva), bodily signals (e.g. electrocardio-sig- 
nals, brain waves, blood pressure waves), and/or other 
bodily stimuli (e.g. respiration) to obtain measurements of 
blood pressure, blood gases, blood coagulation, electrolytes, 
cardiovascular activity, drug levels, respiration rate, stress, 
etc. These medical devices often store measurement data 
which may be retrieved, archived, and/or analyzed. Physi- 
cians, nurses, technicians, and patients typically find such 
measurement data useful in assessing the patient's health, in 
assessing the effectiveness of medications and other treat- 
ments, and in adjusting a patient's current treatment regime 
to obtain better health for the patient 

[0003] To faciliUte retrieval of data, the above medical 
devices typically include a communications port which 
allows communication with another device such as a com- 
puter- Furthermore, the medical devices are often imple- 
mented such that a computing device may control the 
medical device and adjust various operating parameters via 
the communications port. However, in order to retrieve the 
data from the medical device, control the medical device, 
and/or adjust various operating parameters of the medical 
device via the communications port, the computing device 
must be configured to communicate with the medical device 
via a communications protocol designed for the specific 
medical device. 

SUMMARY OF THE INVENTION 

[0004] Systems, client computing devices, server comput- 
ing devices, and methods are disclosed for accessing medi- 
cal device, providing remote access to medical devices, 
and/or remotely accessing medical devices. In accordance 
with one embodiment of the present invention, there is 
provided a method for accessing a medical device operably 
coupled to a computing device. One step of the method 
includes receiving identification information from the com- 
puting device that is indicative of a medical device type. 
Another step of the method includes transferring a protocol 
component to the computing device based upon the identi- 
fication information. The method further includes the step of 
receiving measurement data from the medical device in 
response to the computing device communicating with the 
medical device via the protocol component. 

[0005] Pursuant to another embodiment of the present 
invention, there is provided a method of providing a com- 
puting device with remote access to a medical device. One 
step of the method includes providing the computing device 
with identification information from which a protocol com- 



ponent for use with the medical device is determined. 
Another step of the method includes receiving the proper 
protocol component from the computing device in response 
to providing the computing device with the identification 
information. The method also includes the step of commu- 
nicating with the medical device via the proper protocol 
component. 

[0006] Pursuant to another embodiment of the present 
invention, there is provided a first computing device for 
remotely accessing a medical device operably coupled to a 
second computing device via a network. The first computing 
device includes a storage device comprising a plurality of 
protocol components that configure the second computing 
device to communicate with a plurality of medical devices 
in accordance with communications protocols supported by 
the plurality of medical devices. The first computing device 
also includes a memory comprising a plurality of instruc- 
tions, and a network interface adapted to communicate with 
the second computing device via the network. The first 
computing device further includes a processor operably 
coupled to the storage device, the memory, and the network 
interface. The processor is adapted to execute the plurality of 
instructions to cause, the processor to receive from the 
second computing device via the network interface identi- 
fication information from which a medical device type of the 
medical device coupled to the second computing device is 
determined. The processor is further adapted to execute the 
plurality of instructions to cause to provide protocol com- 
ponent information to the second computing device via the 
network interface which identifies the protocol component 
from the plurality of protocol components for the second 
computing device to use to communicate with the medical 
device. The processor is further adapted to execute the 
plurality of instructions to cause the processor to receive 
measurement data from the medical device via the network 
interface in response to the second computing device com- 
municating with medical device via the protocol component 
identified by the protocol component information. 

[0007] Objects, features, and advantages as well as further 
embodiments will become apparent from the following 
description and the attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] FIG. 1 shows a block diagram of a system which 
incorporates various features of the present invention 
therein; 

[0009] FIG. 2 shows a function block diagram illustrating 
functional components of the system shown in FIG. 1; 

[0010] FIG. 3 is a flowchart illustrating an exemplary 
method of operation for the system of FIG. 1; 

[00 11 ] FIG. 4 is a flowchart illustrating another exemplary 
method of operation for the system of FIG. 1; and 

[0012] FIG. 5 is a flowchart illustrating yet another exem- 
plary method of operation for the system of FIG. 1. 

DETAILED DESCRIPTION OF EXEMPLARY 
EMBODIMENTS 

[0013] While the invention is susceptible to various modi- 
fications and alternative forms, exemplary embodiments 
thereof have been shown by way of example in the drawings 
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and will herein be described in detail. It should be under- 
stood, however, that there is no intent to limit the invention 
to the particular form disclosed, but on the contrary, the 
intention is to cover all modifications, equivalents, and 
alternatives falling within the spirit and scope of the inven- 
tion as defined by the appended claims. 

[0014] A system 1 00 is shown in FIG. 1 and FIG. 2 which 
incorporates various features of the present invention. As 
illustrated, the system 100 includes a server computing 
device 110, a client computing device 120, a medical device 
130 operable coupled to the client computing device 120 via 
a communications link 140, and a network 150 which 
operably couples the client computing device 120 to the 
server computing device 110. In general, the system 100 
automatically or semi-automatically configures the client 
computing devices 120 for communication with medical 
devices 130 that utilize different communications protocols, 
and provides the server computing device 110 remote access 
to the medical devices 130 via the client computing devices 
120 and the network 150. 

[0015] More specifically, the system 100 comprises a set 
of protocol components 204 which the server computing 
device 110 transfers to the client computing devices 120. 
Each protocol component 204 configures the client comput- 
ing devices 120 for commiinication with a specific set of 
medical device models or types of medical devices 130. The 
protocol components are illustratively software components 
which provide a set of rules that govern bow the client 
computing device 120 communicates with a medical device 
130. Illustratively, the protocol components specify rules for 
setting up, carrying out, and terminating a communications 
connection. The protocol components also specify the for- 
mat of the information transmitted across the communica- 
tions connection. More specifically, each protocol compo- 
nent 204 in the exemplary embodiment is adapted to 
configure the client computing devices 120 to send medical 
device configuration information, medical device version 
information, medical device setup information, and medical 
device measurement data to the server computing device 
110. In addition, each protocol component 204 is adapted to 
configure the client computing devices 120 to send updated 
configuration information or setup information to the medi- 
cal device 130. 

[0016] The server computing device 110 is adapted to 
detect, over the network 150, medical devices 130 that are 
operably coupled to the client computing devices 120. 
Illustratively, the server computing device 110 is adapted to 
query the connected medical devices 130 for medical device 
version information, medical device configuration informa- 
tion, medical device setup information, and medical device 
measurement data. While the server computing device 110 
and the client computing device 120 are typically separate 
computing devices, the server computing device 110 may 
also function as a client computing device 120. Accordingly, 
if a medical device 130 is coupled to a server computing 
device 110 that also provides functionality of the client 
computing device 120, then information need not be trans- 
ferred across a network 150. 

[0017] Now referring to FIG. 1 in more detail, the server 
computing device 110 of the exemplary system 100 includes 
a processor 112, memory 114, a storage device 116, a 
network interface 118, and a system bus U9. The exemplary 



server computing device 110 as depicted in FIG. 1 is 
generally illustrative of server computer systems and web 
servers manufactured by Dell Computer Corporation of 
Round Rock, Tex., Gateway, Inc. of San Diego, Calif., and 
Compaq Computer Corporation of Houston, Tex. While the 
server computing device 110 may be implemented with a 
server computer system or web server from the above 
vendors, the server computing device 110 may alternatively, 
or in addition, include Other computing devices such as 
network server appliances, server farms, server clusters, 
and/or network accessible storage devices. 

[0018] The processor 112 of the exemplary server com- 
puting device 110 includes a single x86 processor from Intel 
or AMD. However, the processor 112 may alternatively 
include one or more processors utilizing very long instruc- 
tion words, (VLIW) code morphing, complex instruction set 
computer (CISC), reduced instruction set computer (RISC), 
single instruction/multiple data (SfMD), multiple instruc- 
tion/multiple data (MIMD), or other architectures from 
vendors such as Compaq, National Semiconductor Corpo- 
ration, Motorola and Transmeta Corporation. The processor 
112 is generally operable to execute software and/or firm- 
ware routines stored in the memory 114. As a result of 
executing the software and/or firmware routines of the 
memory 114, the processor 112 controls the general opera- 
tion of the server computing device 110. More specifically, 
the processor 112 as a result of executing software and/or 
firmware routines of the memory 114 is generally operable 
to configure the client computing devices 120 for commu- 
nication with the medical devices 130. Further, the processor 
112 as a result of executing the software and/or firmware 
routines of the memory 114 is generally operable to config- 
ure the server computing device 110 to retrieve measure- 
ment data from the medical devices 130 via the client 
computing devices 120, archive measurement data received 
from the medical devices, process the measurement data 
received from the medical devices, and/or provide the client 
computing devices 120 with processed measurement data. 

[0019] The memory 114 of the exemplary server comput- 
ing device 110 is operable to store data and instructions used 
by the processor 112. To this end, the memory 114, in an 
exemplary embodiment, includes standard random access 
memory for storing the data and software instructions 
needed by the processor 112. However, the memory 114 may 
alternatively include other volatile memory types such as 
DRAM, SDRAM, and SRAM for storing data and software 
instructions and/or non-volatile memory such as ROMs, 
PROMs, EEPROMs, and flash memory for storing data and 
firmware instructions. 

[0020] The storage device 116 of the exemplary server 
computing device 110 is generally operable to store data 
and/or software instructions of the exemplary server com- 
puting device 110. To this end, the storage device 116 may 
include various computer readable and/or writeable media 
devices such as bard disk drives, floppy disk drives, CD- 
ROM drives, DVD-RAM drives, RAID devices, and/or 
Disk-On Chip devices to name a few. Furthermore, the 
storage device 116 may store data in a number of different 
manners such as raw data to the media of the storage device 
116, files in a file system of the storage device 116, and/or 
data, records, or objects in a database of the storage device 
116. Moreover, the storage device 116 may include multiple 
media devices and may be distributed among several com- 
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puting devices such as other servers of a server farm, other 
database servers, or other network accessible storage (NAS) 
devices. 

[0021] The network interface 118 of the exemplary server 
computing device U0 generally operably couples the exem- 
plary server computing device 110 to the network 150 such 
that the server computing device 110 may communicate with 
the client computing devices 120 that are also operably 
coupled to the network 150. To this end, the network 
interface 118 of the exemplary embodiment comprises a 
network interface controller such as an Ethernet controller or 
Token Ring controller that connects the server computing 
device 110 to the network 150 via a local area network, 
firewall, gateway, and/or router. However, the network inter- 
face 118 may alternatively, or in addition, include an analog 
modem for use over POTS telephone lines such as a 28. 8 K 
or 56K modem, or a digital modem such as a Cable modem 
for use over a cable distribution network, an ISDN modem 
for use over an ISDN telephone line, or a DSL modem for 
use over a DSL telephone line. 

[0022] The system bus 119 of the exemplary server com- 
puting device 110 is generally operable to interconnect the 
processor 112, the memory 114, the storage device 116, and 
the network interface 118. The system bus 119 in the 
exemplary embodiment includes an address bus and data bus 
which enable the various components of the exemplary 
server computing device 110 to communicate with one 
another. Furthermore, the system bus 119 may be imple- 
mented with one or more buses utilizing one or more bus 
architectures such as PCI, ISA, and VME. 

[0023] As can be seen from FIG. 1, the exemplary client 
computing device 120 includes a processor 122, memory 
123, a storage device 124, a network interface 125, a device 
interface 126, one or more user I/O devices 127, and a 
system bus 128. The exemplary client computing device 120 
as depicted in FIG. 1 is generally illustrative of personal 
computer systems, desktop computer systems, and/or work- 
stations manufactured by Dell Computer Corporation of 
Round Rock, Tex., Gateway, Inc. of San Diego, Calif., and 
Compaq Computer Corporation of Houston, Tex. While the 
client computing device 120 may be implemented with a 
personal computer system, desktop computer system, and/or 
workstation from the above vendors, the client computing 
device 120 may alternatively, or in addition, include other 
computing devices such as network enabled (more prefer- 
ably Internet enabled) computing devices such as handheld 
computers, laptop computers, set-top boxes, network appli- 
ances, and/or gaming consoles. 

[0024] The processor 122 of the exemplary client com- 
puting device 120 includes a single x86 processor from Intel 
or AMD. However, the processor 122 may alternatively 
include one or more processors utilizing VLTW, code mor- 
phing, CISC, RISC, SIMD, MIMD, or other architectures 
from vendors such as Compaq, National Semiconductor 
Corporation, and Transmeta Corporation. As a result of 
executing the software and/or firmware routines of the 
memory 123, the processor 122 controls the general opera- 
tion of the client computing device 120. More specifically, 
the processor 122 as a result of executing software and/or 
firmware routines of the memory 123 is generally operable 
to configure the client computing device 120 for communi- 
cation with the medical devices 130. Further, the processor 



122 as a result of executing the software and/or firmware 
routines of the memory 123 is generally operable to con- 
figure the client computing device 120 to determine the 
medical device type of a medical device 130 operably 
coupled thereto, obtain from the server computing device 
110 a protocol component 204 (See, FIG. 2.) suited for 
communicating with the medical device 130 operably 
coupled thereto, and/or communicate with the medical 
device 130 via the protocol component 204. 

[0025] The memory 123 of the exemplary client comput- 
ing device 120 is operable to store data and instructions used 
by the processor 122. To this end, the memory 123, in an 
exemplary embodiment, includes standard random access 
memory for storing the data and software instructions 
needed by the processor 122. However, the memory 123 
may alternatively include other volatile memory types such 
as DRAM, SDRAM, and SRAM for storing data and 
software instructions and/or non-volatile memory such as 
ROMs, PROMs, EEPROMs, and flash memory for storing 
data and firmware instructions. 

[0026] The storage device 124 of the exemplary client 
computing device 120 is generally operable to store data 
and/or software instructions of the exemplary client com- 
puting device 120. To this end, the storage device 124 may 
include various computer readable and/or writeable media 
devices such as hard disk drives, floppy disk drives, CD- 
ROM drives, DVD-RAM drives, RAID devices, and/or 
Disk-On Chip devices to name a few. Furthermore, the 
storage device 124 may store data in a number of different 
manners such as raw data to the media of the storage device 
124, files in a file system of the storage device 124, and/or 
data, records, or objects in a database of the storage device 
124. Moreover, the storage device 124 may include multiple 
media devices. 

[0027] The exemplary client computing device 120 may 
alternatively be implemented such that the same hardware 
components that implement the memory 123 also implement 
the storage device 124. For example, the exemplary client 
computing device 120 may be implemented with memory 
chips that implement both the functionality of the memory 

123 and the storage device 124. Many special purpose 
computing devices such as handheld computing devices 
(e.g. Palm Pilots) and Internet enabled cellular phones which 
could be used to implement the client computing device 120 
are implemented in such a manner. 

[0028] The network interface 125 of the exemplary client 
computing device 120 generally operably couples the exem- 
plary client computing device 120 to the network 150 such 
that the client computing device 120 may communicate with 
the server computing device 110 via the network 150. To this 
end, the network interface 125 of the exemplary embodi- 
ment comprises an analog modem for use over POTS 
telephone lines such as a 28 .8 K or 56 K modem, or a digital 
modem such as a Cable modem for use over a cable 
distribution network, an ISDN modem for use over an ISDN 
telephone line, or a DSL modem for use over a DSL 
telephone line. However, the network interface 118 may 
alternatively, or in addition, include a network interface 
controller such as an Ethernet controller or Token Ring 
controller that can be used to connect the client computing 
device 120 to the network 150 via a local area network, 
firewall, gateway, and/or router. 
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[0029] As shown, the exemplary client computing device 
120 further includes the device interface 126. The device 
interface 126 is generally operable to establish a physical 
communications link 140 between the client computing 
device 120 and the medical device 130. To this end, the 
device interface 126 of the exemplary client computing 
device 120 includes a standard RS-232 serial port to which 
the medical device 130 may be operably coupled via an 
RS-232 cable. 

[0030] However, the device interface 126 may alterna- 
tively, or in addition, include other communications mecha- 
nisms such as a parallel port, a SCSI port, a USB port, a 
1394 port (i.e. Fire Wire or I-Link port), a Fibre Channel 
port, a network interface controller, or some other type of 
communications port to which a user may couple a corre- 
sponding communications port of the medical device 130 
via an appropriate cable or connector. The device interface 
126 may alternatively, or in addition, include wireless tech- 
nologies such as RF and/or IR transmitter/receivers to 
establish the physical communications link 140 between the 
client computing device 120 and the medical device 130. 

[0031] As depicted, the client computing device 120 
includes one or more user I/O devices 127. The user I/O 
devices 127 in general provide a user of the client computing 
device 120 with mechanisms for entering information into 
the client computing device 120, receiving information from 
the client computing device 120, and/or controlling the 
operation of the client computing device 120. For example, 
the user I/O devices 127 may include cathode ray tubes 
(CRT), liquid crystal displays (LCD), light emitting diodes 
(LED), printers, and/or' other output devices that are oper- 
able to visually present information to a user of the exem- 
plary client computing device 120. The user I/O devices 127 
may also include sound cards, wave generators, sequencers, 
mixers, speakers, and/or other audio devices that are used to 
audibly present information to a user of the exemplary client 
computing device 120. 

[0032] Further, the user I/O devices 127 may include a 
mouse, a keyboard, a touch pad, a push button, a scanner, a 
stylus, a touch screen, and/or other input devices that 
provide a user of the exemplary client computing device 120 
with an interface to directly control the operation of the 
exemplary client computing device 120 and/or indirectly 
control the operation of the server computing device 110 and 
the medical device 130. 

[0033] The system bus L28 is generally operable to inter- 
connect the processor 122, the memory 123, the storage 
device 124, the network interface 125, the device interface 
126, and the user I/O devices 127. To this end, the system 
bus 128 in the exemplary embodiment includes bus lines 
and/or traces which enable the various components of the 
exemplary client computing device 120 to communicate 
with one another. Furthermore, the system bus 128 may be 
implemented with one or more buses utilizing one or more 
bus architectures such as PCI, ISA, and VME. 

[0034] As shown, the system 100 further includes a medi- 
cal device 130. The medical device 130 of the system 100 is 
generally operable to monitor one or more biological/physi- 
ological conditions and communicate with the client com- 
puting device 120 via the physical communications link 140 
established between the client computing device 120 and the 
medical device 130. In an exemplary embodiment, the 



medical device 130 includes a glucose meter such as the 
glucose meters manufactured by Roche Diagnostics Corpo- 
ration which are generally operable to measure blood glu- 
cose levels of blood applied to test strips. While the medical 
device 130 of the exemplary embodiment includes a glucose 
meter, the medical device 130 could be implemented to 
monitor and/or analyze other biological/physiological 
parameters or conditions such as body fluids or bodily 
functions (e.g. blood, urine, saliva), bodily signals (e.g. 
electrocardio-signals, brain waves, blood pressure waves), 
and/or other bodily stimuli (e.g. respiration) to obtain mea- 
surements of blood pressure, blood gases, blood coagula- 
tion, electrolytes, cardiovascular activity, drug levels, respi- 
ration rate, ( stress, etc. 

[0035] As can be seen from FIG. 1, the exemplary medi- 
cal device 130 includes a processor 132, memory 133, a 
communications interface 136, one or more user I/O devices 
137, and ft system bus 138. The processor 122 of the 
exemplary medical device 130 includes a single micropro- 
cessor or microcontroller, however, the processor 122 may 
alternatively include more than one processor. As a result of 
executing the software and/or firmware routines of the 
memory 133, the processor 132 controls the general opera- 
tion of the medical device 130. More specifically, the 
processor 132 as a result of executing software and/or 
firmware routines of the memory 133 is generally operable 
to configure the medical device 130 to obtain measurement 
data indicative of a. biological/physiological condition. 

[0036] Further*, the processor 132 as a result of executing 
the software and/or firmware routines of the memory 133 is 
generally operable to control communication between /the 
client computing device 120 and the medical device 130 in 
accordance with a particular communications protocol 
which may be specific to the medical device 130. In an 
exemplary embodiment, the system 100 supports several 
different models and/or types of medical devices 130 which 
may use different communications protocols. In general, 
these different models and/or types of medical devices 130 
may utilize protocols that define different procedures for 
formatting data and the procedure used to transfer the data. 
For example, different medical devices 130 may utilize (i) a 
different message or packet formal, (ii) a different transfer 
rate, (in) a different error detection scheme, (iv) a different 
error correction scheme, (v) a different command set, and/or 
(vi) a different compression scheme to name a few. 

[0037] The memory 133 of the exemplary medical device 
130 is operable to store data and instructions used by the 
processor 132. To this end, the memory 133, in an exemplary 
embodiment, includes random access memory for storing 
data, software instructions, and/or other information needed 
by the processor 132. However, the memory 133 may 
alternatively include other volatile memory types such as 
DRAM, SDRAM, and SRAM for storing data and software 
instructions and/or non-volatile memory such as ROMs, 
PROMs, EEPROMs, and flash memory for storing data and 
firmware instructions. 

[0038] As shown, the exemplary medical device 130 fur- 
ther includes the communications interface 136. The com- 
munications interface 136 is generally operable to establish 
the physical communications link 140 between the client 
computing device 120 and the medical device 130. To this 
end, the communications interface 136 of the exemplary 
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medical device 130 includes a standard RS-232 serial port to 
which the client computing device 120 may be operably 
coupled via an RS-232 cable. 

[0039] The communications interface 136, however, may 
alternatively, or in addition, include other communications 
mechanisms such as a parallel port, a SCSI port, a USB port, 
a 1394 port (i.e. Fire Wire or I-Link port), a Fibre Channel 
port, a network interface controller, or some other type of 
communications port to which a user may couple a corre- 
sponding communications port of the client computing 
device 120 via an appropriate cable or connector. The 
communications interface 136 may alternatively, or in addi- 
tion, include wireless technologies such as RF and/or IR 
transmitter/receivers to establish the physical communica- 
tions link 140 between the client computing device 120 and 
the medical device 130. 

[0040] The medical device 130 further includes one or 
more user I/O devices 137. The user I/O devices 137 in 
general provide a user of the medical device 130 with 
mechanisms for entering information into the medical 
device 130, receiving information from the medical device 
130, and/or controlling the operation of tbe medical device 
130. For example, the user I/O devices 137 may include 
cathode ray tubes (CRT), liquid crystal displays (LCD), light 
emitting diodes (LED), printers, and/or other output devices 
that are operable to visually present information to a user of 
the exemplary medical device 130. The user I/O devices 137 
may also include sound cards, wave generators, sequencers, 
mixers, speakers, and/or other audio devices that are used to 
audibly present information to a user of the exemplary 
medical device 130. 

[0041] Further, the user I/O devices 137 of the medical 
device 130 may include a mouse, a keyboard, a touch pad, 
a push button, a scanner, a stylus, a touch screen, and/or 
another input device that provides a user of the exemplary 
medical device 130 with an interface to directly control the 
operation of the exemplary medical device 130. The medical 
device 130 may also be implemented with no user I/O 
devices 137, and simply leverage tbe user I/O devices 127 
of the client computing device 120. However, even a medi- 
cal device 130 that highly leverages tbe user I/O devices 127 
of the client computing device 120 will usually still have a 
few user I/O devices 137 such as an LED that provides 
visual feedback that the medical device 130 is powered, an 
LED that provides visual feedback that the physical com- 
munications link 140 has been established, and/or a button 
or switch to power tbe medical device 130 on or off. 

[0042] The system bus 138 is generally operable to inter- 
connect the processor 132, tbe memory 133, tbe communi- 
cations interface 136, and the user I/O devices 137. To this 
end, tbe system bus 138 in the exemplary embodiment 
includes bus lines and/or traces which enable the various 
components of tbe medical device 130 to communicate with 
one another. Furthermore, the system bus 138 may be 
implemented with one or more buses utilizing one or more 
bus architectures such as PCI, ISA, VME, and PC- 104. 

[0043] As depicted in FIG. 1, the network 150 of the 
exemplary system 100 operably couples the client comput- 
ing device 120 to the server computing device 110. The 
network 150 may illustratively include multiple public or 
private LANs and/or WANs (not shown) that are operably 
coupled to one another via routers, switches, hubs, gate- 



ways, proxies, and/or firewalls (not shown). In an exemplary 
embodiment, the network 150 utilizes the Internet to provide 
ubiquitous access to the server computing device 110 from 
the client computing devices 120. / 

[0044] Referring now to FIG. 2, a functional block dia- 
gram illustrates the interaction of data and functional com- 
ponents of the exemplary system 100. In general, the func- 
tional components depicted in FIG. 2 are implemented with 
software and/or firmware that is executed by tbe server 
computing device 110 and the client computing device 120. 
While the functional components of FIG. 2 arc implemented 
via software and/or firmware and are so described below, 
those skilled in tbe art may elect to implement all or portions 
of the functional components with discrete analog circuit 
components, discrete digital circuit components, integrated 
analog circuits, integrated digital circuits, and/or integrated 
analog/digital hybrid circuits without undue experimenta- 
tion and such implemented functional components may 
replace all or a portion of tbe hardware components illus- 
trated in FIG. 1. 

[0045] As illustrated, the exemplary server computing 
device 110 includes a server transport agent 202, protocol 
components 204, device data 206, patient data 208, and 
device identification components 214. Furthermore, the 
exemplary client computing device 120 includes a user 
interface 210, a client transport agent 212, a device identi- 
fication component 214, an update component 216, and a 
protocol component 204. 

[0046] Tbe server transport agent 202 and tbe client trans- 
port agent 212 respectively configure the server computing 
device ,110 and the, client computing device 120 for com- 
munication therebetween via the network 150. In an exem- 
plary embodiment, the server transport agent 202 and tbe 
client transport' agent 212 configure the server computing 
device U0 and client computing device 120 to utilize the 
HTTP (hypertext transport protocol) over the TCP/IP net- 
work protocol. To this end, the server transport agent 202 of 
the exemplary embodiment comprises an HTTP server that 
is operable to receive HTTP requests from one or more 
client computing devices 120 and provide the client com- 
puting devices 120 with the requested information. The 
server transport agent 202 may include any one of a number 
of currently available HTTP servers or web application 
servers such as the Internet Information Server available 
from Microsoft Corporation, the Apache HTTP Server avail- 
able from tbe Apache Group, and tbe Zope web application 
server available from Digital Creations, Inc. The server 
transport agent 202 may support other transport protocols 
such as FTP, TFTP, SMTP, etc. or other network protocols 
such as UDP, SMB. NetBUl, etc. in addition to or instead of 
the HTTP protocol and tbe TCP/IP protocols, 

[0047] As illustrated, the server computing device 110 
comprises several protocol components 204 that when trans- 
ferred to a client computing device 120 configure the client 
computing device 120 to use a particular communications 
protocol when communicating with an identified medical 
device 130. As indicated above, the exemplary system 100 
supports medical devices 130 which utilize different com- 
munications protocols. Accordingly, the server computing 
device 110 maintains protocol components 204 which when 
executed by the client computing device 120 cause the client 
computing device 120 to communicate with a medical 
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device 130 in the proper communications protocol for the 
medical device 130. To this end, the exemplary server 
computing device 110 maintains a separate protocol com- 
ponent 204 for each type of medical device 130 that the 
system 100 supports. 

[0048] The server computing device 110 may alternatively 
include protocol components 204 that support more than one 
communications protocol or that can configure the client 
computing device 130 to communicate with more than one 
type of medical device 130. While including multiple func- 
tionality into a single protocol component 204 reduces the 
number of protocol components 204 that the server com- 
puting device 110 needs to maintain, these multi-functional 
protocol components 204 are also likely to be larger in size 
than a protocol component 204 that merely implements a 
communications protocol for a single type of medical device 
130. A larger protocol component 204 takes longer to 
transfer to the client computing device 120; however, a 
client computing device 120 that is used with several types 
of medical devices 130 may more than recoup this transfer 
time by not needing to download as many protocol compo- 
nents 204 from the server computing device 110. 

[0049] In the exemplary embodiment, the protocol com- 
ponents 204 are implemented as ActiveX components which 
can be downloaded and executed by the client computing 
device "120 via a web browser. However, the protocol 
components 204 may also be implemented using other 
software technologies such as COM, DCOM, Java, JavaS- 
cript, VBScript, Perl, Python, as well as native applications 
written in the language of the developers choice which could 
be executed on the client computing device 120 via various 
RPC techniques. Furthermore, by utilizing interpreted lan- 
guages such as JavaScript and VBScript or byte compiled 
languages such as Java, Perl, and Python, the server com- 
puting device 110 may maintain a single version of a 
protocol component 204 or a small number of versions of a 
particular protocol component 204 in order to support a wide 
range of client computing device platforms (i.e. hardware 
and operating system combinations.) In other words, the 
server computing device 110 may be efficiently imple- 
mented to supported a wide range of client computing 
devices 110 (e.g. computer systems using the Mcintosh, 
Windows, and/or Lioux operating systems, Palm Pilots, 
Handspring Visors, Internet enabled cellular phones, etc.). 

[0050] As illustrated in FIG. 2, the server computing 
device 110 also includes device data 206 and patient data 
208 stored in the memory 114 and/or the storage device 116. 
The device data 206 generally includes information regard- 
ing types of medical devices 130 that the system 100 
supports and which of the protocol components 204 supports 
a certain medical device 130. The server computing device 
110 utilizes the device data 206 to determine which of the 
protocol components 204 is the proper protocol component 
204 for a given medical device 130 so that the proper 
protocol component 204 is transferred to the client comput- 
ing device 120 if needed. 

[0051] The patient data 208 generally includes biological 
and/or physiological data collected from patients being 
monitored by the system 100. Moreover, the patient data 208 
may further include patient identification information (e.g. 
name, date of birth, address, etc) and authentication infor- 
mation (e.g. useraame/password, web cookie text, client 



computing device address, medical device serial number, 
client computing device network address, etc.) which may 
be used to verify the identify of a given patient and/or 
correlate a given patient with prior biological/physiological 
data collected by the server computing device 110. The 
system 100 may also allow anonymous access in which case 
the server computing device 110 may maintain no patient 
data or may maintain patient data in an anonymous manner 
that still enables a patient to obtain their collected biological/ 
physiological data. Anonymous access enables a patient to 
retrieve, view, and/or analyze the current biological/physi- 
ological data of the medical device 130 without fear of 
someone tying the data to the patient. 

[0052] The user interface 210 of the client computing 
device 120 is generally operable to provide a user (e.g. a 
patient, nurse, physician, etc.) with a mechanism for con- 
trolling operation of the system 100 in regard to the client 
computing device 120 and the medical device 130. More 
specifically, the user interface 210 of the exemplary embodi- 
ment is operable to display HTML (hyper- text markup 
language) documents and HTML forms. However, the user 
interface 210 could display information in other formats 
such RTF, PDF, and ASCII Text or other markup language 
formats such as SGML, XML, Tex, and/or LaTeX. 

[0053] In an exemplary embodiment, the user interface 
210 and the client transport agent 212 described above are 
implemented with a standard web browser such as Internet 
Explorer available from Microsoft Corporation of Redmond, 
Wash, or Netscape Communicator available from Netscape 
Communications Corporation of Mountain View, Calif, and 
the TCP/IP protocol portion of the client transport agent 212 
is implemented with the TCP. These standard web browsers 
among other things are operable to send and receive packets 
of information that conform to the HTTP and the TCP/IP 
protocols, send requests for HTML documents, receive 
HTML documents, display HTML documents, and send data 
that a user has input into a HTML form. 

[0054] Alternatively, the user interface 210 may be imple- 
mented as a native custom application of the client comput- 
ing device 120 that is specifically designed for the system 
100. The custom application could be implemented to dis- 
play HTML and other markup language documents in a 
manner similar to a standard web browser. However, the 
custom application is more likely to be implemented to 
receive information from the server computing device 110 in 
a non-markup language format, and display the information 
via a customized graphical interface. 

[0055] The device identification component 214 of the 
exemplary client computing device 120 generally causes the 
client computing device 120 to identify the medical device 
130 without the need for the user to enter identifying 
information for the medical device 130. To this end, the 
device identification component 214 in an exemplary 
embodiment scans a predetermined port of the client com- 
puting device 120 to determine the type of medical device 
130 operably coupled to the predetermined port The exact 
procedure that the device identification component 214 
utilizes to identify the medical device 130 operably coupled 
to the client computing device 120 depends upon the com- 
munications protocols utilized by the medical devices sup- 
ported by the system 100. Several known techniques may be 
used such as identifying the medical device 130 based upon 
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(i) responses received from the medical device 130 due to 
stimulus signals applied to the medical device 130, (ii) 
identification codes retrieved from the medical device 130, 
(iii) serial numbers retrieved from the medical device 130, 
and/or (iv) other information retrieved from the medical 
device 130. It is understood that device identification com- 
ponent 214 may include a manual device identification such 
as a drop down box, check box, or other manual entry. 

[0056] Besides merely scanning a predetermined port for 
the medical device 130, the device identification component 
214 may allow a user to specify via the user interface 210 to 
which port the medical device 130 is operably coupled. 
Further, the identification component 214 could simply scan 
all ports of a particular type (e.g. all USB ports, all SCSI 
ports, all parallel ports, wireless interfaces, etc) or scan a 
user-definable set of ports. 

[0057] In an exemplary embodiment, the device identifi- 
cation component 214 comprises an executable program or 
script which when executed by the client computing device 
120 generally causes the client computing device 120 to 
identify the medical device 130 as described above. The 
device identification component 214 may alternatively com- 
prise hardware, firmware, or a combination of hardware, 
firmware, and/or software that configure the client comput- 
ing device 120 to identify the medical device 130. 

[0058] The update component 216 in general ensures that 
the client computing device 120 utilizes the proper protocol 
component 204 for the identified medical device 130. To this 
end, the update component 216 in an exemplary embodi- 
ment generally determines which protocol components 204 
(if any) are currently stored in the memory 123 and/or the 
storage device 124 of the client computing device 120 and 
whether any of the protocol components 204 of the client 
computing device 120 is the proper protocol component 204 
for the identified medical device 130. If the update compo- 
nent 216 determines that client computing device 120 does 
not have a copy of the proper protocol component 204 for 
the identified medical device 130, then the update compo- 
nent 216 operates in conjunction with the client transport 
agent 212 to obtain a copy of the correct protocol component 
204 from the server computing device 110. 

[0059] While the update component 216 could be imple- 
mented as a separate software, firmware, and/or hardware 
component, the update component 216 in an exemplary 
embodiment is implemented with the standard web browser 
that is also used to implement the user interface 212 and 
transport agent 214 of the client computing device 120. Web 
browsers generally provide mechanisms which enable 
remote computer systems such as the server computing 
device 110 to cause the client computing device 120 to 
execute software routines. For example, many web browsers 
support execution of Java Applets, JavaScript, ActiveX 
Controls, and other types of software technologies by which 
the server computing device 110 can cause the client com- 
puting device 130 to execute software in response to infor- 
mation received from the server computing device 110. 

[0060] Moreover, web browse rs ge nerally also include the 
ability to determine whether a particular software compo- 
nent such as an ActiveX Control, a plug-in application, or a 
Java Applet is already installed on the client computing 
device 120 in response to information received from a server 
computing device 110. Further, web browsers generally also 



include the ability to determine the version of such installed 
software components. Web browsers also generally include 
the ability to download and install via the client transport 
agent 212 a needed software component such as an ActiveX 
Control, a plug-in application, or a Java Applet from the 
server computing device 110 in response to information 
received from the server computing device 110. 

[0061] Moreover, web browsers also generally include the 
ability to cache information received from a server comput- 
ing device 110 and determine whether the information in the 
cache is up-to-date with corresponding information of the 
server computing device 110. In this manner, the web 
browser pf the client computing device 120 can prevent the 
repetitive transfer of the same information from the server 
computing device 110 to the client computing device 120. In 
other words, if the client computing device 120 requests a 
particular resource from the server computing device 110 
and the client computing device 120 already has a copy of 
that resource in the cache, then the web browser can cause 
the cb'ent computing device 120 to use the cached version of 
the resource, thus eliminating a transfer of the resource from 
the server computing device 110 to the client computing 
device 120. 

[0062] As indicated above, the protocol components 204 
generally configure the client computing device 120 to use 
a particular communications protocol when communicating 
with an identified medical, device 130. The exemplary sys- 
tem 100 supports iriedical devices 130 which utilize different 
communications protocols. Accordingly, the server comput- 
ing device 110 maintains protocol components 204 which 
when executed by the client computing device 120 cause the 
client computing device 120 to communicate with a medical 
device 130 in the proper communications protocol for the 
medical device, 130. In an exemplary embodiment, the 
protocol components 204 comprise software such as Java 
Applets, JavaScripts, ActiveX Controls, etc. which is 
executed by the client computing device 130 in response to 
information received from the server computing device 110. 

[0063] A flowchart depicting an exemplary method of 
operation 300 is illustrated in FIG. 3. As illustrated, the 
exemplary method 300 begins in step 302 with establishing 
a physical communications link 140 between the client 
computing device 120 and the medical device 130. In an 
exemplary embodiment, a user of the system establishes the 
physical communications link 140 by coupling a interface 
cable between a port (e.g. serial I/O port) of the medical 
device 130 and a corresponding port (e.g. COM port 1) of 
the client computing device 120. However, if the medical 
device 130 includes a wireless communication mechanism 
such as 1R and/or RF transmitters/receivers, then the physi- 
cal communications link 140 is established by simply plac- 
ing the medical device 130 within transmission range of the 
corresponding IR and/or RF transmitters/receivers of the 
client computing device 120. 

[0064] In step 304 of the exemplary method 300, the client 
computing device 120 establishes communications with the 
server computing device 110. In an exemplary embodiment, 
the client computing device 120 establishes communications 
with the server computing device 110 in response to a user 
requesting via the user interface 210 that the client transport 
agent 212 establish communications with the server com- 
puting device 110. In particular, the user in the exemplary 
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embodiment requests via a web browser of the user interface 
210 that the web browser connect to the server computing 
device 110 and associated transport agent 202 identified by 
a particular URI (Universal Resource Identifier), URL (Uni- 
versal Resource Locator), PURL (Persistent Uniform 
Resource Locator) and/or URN (Universal Resource Name). 

[0065] The server computing device 110 in step 306 
attempts to authenticate the user, the client computing 
device 120, and/or the medical device 130. In an exemplary 
embodiment, the server computing device 110 attempts to 
authenticate the user, the client computing device 120, 
and/or the medical device 130 via various authentication 
schemes in order to enable a user to retrieve previously 
collected biological/physiological data, and/or ensure that 
collected biological/physiological data is kept private. In an 
exemplary embodiment, the user via the user interface 210 
enters a usemame and password which the server computing 
device 110 compares to username/password pair of the 
maintained patient data 208 to determine whether the user 
has entered a valid username/password pair. However, in 
environments where security/privacy is not a concern, an 
alternative embodiment of the server computing device 110 
does not authenticate the user, the client computing device 
120, and/or the medical device 130. It should be appreciated 
that other authentication methods are also suitable. For 
example, authentication may be based further upon or alter- 
natively upon the network address of client computing 
device 120, the serial number of the medical device 130, 
stored authentication keys (e.g. PGP keys), etc. 

[0066] In step 308, the server computing device 110 
determines whether the attempt to authenticate the user, the 
client x computing device 120, and/or the medical device 130 
succeeded. In an exemplary embodiment in which the server 
computing device 110 utilizes username/password pairs for 
authentication, the server computing device 110 determines 
that the authentication attempt failed if the received user- 
name/password pair is invalid. In step 310, the server 
computing device 110 performs various other actions in 
response to receiving an invalid username/password pair 
such as logging the invalid username/password pair, logging 
the network address of the client computing device 120, 
blocking connections from the client computing device 120 
if a threshold number of attempts is exceeded, etc. After 
performing the various action of step 308, the server com- 
puting device 110 returns to step 306 in order to re-attempt 
to authenticate the user, the client computing device 120, 
and/or the medical device 130. 

[0067] The device identification component 214 of the 
client computing device 120 in step 312 provides the server 
computing device 110 with device information from which 
the server computing device 110 determines the proper 
protocol component 204 to be used with the medical device 
130. As indicated above, the device identification compo- 
nent 214 generally interrogates the medical device 130 via 
a series of signals, receives signals from the medical device 
130 in response to the interrogation, and discerns the type of 
medical device 130 connected to the client computing 
device 120 based upon the signals received from the medical 
device 130. The signals received from the medical device 
130 may include ACK signals or other signals indicative of 
information such as a serial number, model number, device 
type, version number, etc. At any rate, the device identifi- 
cation component 214 provides the server computing device 



110 with device information via the client transport agent 
212 from which the server computing device 110 ascertains 
the type of medical device 130 operably coupled to the client 
computing device 120. 

[0068] The server computing device 110 then determines 
in step 314 the proper protocol component 204 to commu- 
nicate with the identified medical device 130. In particular, 
the server computing device 10 in the exemplary embodi- 
ment utilizes the device data 206 and the device information 
received from the device identification component 214 to 
select the proper protocol component 204 for the client 
computing device 120 to use in commumcating with the 
identified medical device 130. 

[0069] The server computing device 110 in step 316 
provides the update component 216 of the client computing 
device 120 with protocol component information that iden- 
tifies the proper protocol component 204 to be used with the 
identified medical device 130. In an exemplary embodiment, 
the server computing device 110 merely transfers to. the 
client computing device 120 an HTML document that 
includes a reference to the proper ActiveX Control for the 
client computing device 120 to execute in order to commu- 
nicate with the medical device 130. 

[0070] As result of receiving the protocol component 
information from the server computing device 110, the client 
computing device 120 in step 318 determines whether the 
client computing device 120 needs to receive a copy of the 
proper protocol component 204 from the server computing 
device 110. In an exemplary embodiment, the web browser 
of the user interface 210 processes an HTML document 
received from the server computing device 110 which causes 
the update component 216 to verify that the client comput- 
ing device 120 already has a current version of the proper 
protocol component 204 referenced by the HTML docu- 
ment. If the update component 216 determines that the client 
computing device 120 already has the current version, then 
the client computing device 120 proceeds to step 312 in 
order to communicate with the medical device 130 via the 
protocol component 204. 

[0071] If the client computing device 120 determines that 
the client computing device 120 needs a copy of the proper 
protocol component 204, then the client computing device 
120 in step 320 receives a copy of the proper protocol 
component 204 from the server computing device 110. In 
particular, the client transport agent 212 in an exemplary 
embodiment retrieves a copy of the proper protocol com- 
ponent 204 from the location specified in an HTML docu- 
ment received from the server computing device 110. 

[0072] The update component 216 of the client computing 
device 120 ensures that the client computing device 120 
includes the proper protocol component 204 for the medical 
device 130. As a result, the client computing device 120 
communicates with the medical device 130 utilizing the 
proper protocol component 204 even if the protocol com- 
ponent 204 is later revised and even if the client computing 
device 120 did not previously have the proper protocol 
component 204 for the medical device 130. 

[0073] The client computing device 120 then in step 322 
executes the proper protocol component 204 in order to 
transfer data and/or control information between the client 
computing device 120 and the medical device 130. In an 
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exemplary embodiment, the client computing device 120 
executes the proper protocol component 204 referenced by 
the HTML document received from the server computing 
device 110. 

[0074] As a result of executing the proper protocol com- 
ponent 204, the client computing device 120 performs 
various operations in regard to communicating with the 
medical device 130 on the behalf of the client computing 
device 120 and/or the server computing device 110. For 
example, the server computing device 110 may cause client 
computing device 120 to issue commands to the medical 
device 130 via the protocol component 204 which cause the 
medical device 130 to adjust an internal clock, clear stored 
measurement data, retrieve stored measurement data, update 
calibration or other parameters used to obtain measurement 
data, perform a test to obtain measurement data, or other 
tasks. 

[0075] Similarly, the server computing device 110 may 
cause the client computing device 120 to transfer measure- 
ment data, device status data, etc. from the medical device 
130 to the server computing device 110. More specifically, 
the client computing device 120 obtains the data from the 
medical device 130 via the protocol component 204, and 
after completing the transfer of data from the medical device 
130 to the client computing device 120, the client computing 
device 120 transfers the data to the server computing device 
110. However, the client computing device 120 may alter- 
natively begin the transfer of received data to the server 
computing device 110 before receiving all of the requested 
data from the medical device 130. 

[0076] As indicated above, some of the operations per- 
formed on behalf of the server computing device 110 cause 
the client computing device 120 to provide the server 
computing device 110 with data such as measurement data, 
device status data, etc. Accordingly, the server computing 
device 110 in step 322 processes data received from the 
measurement device 130 via the cb'ent computing device 
120. For example, the server computing device 110 in an 
exemplary embodiment stores measurement data received 
from the client computing device 120 with the patient data 
208 such that the measurement data is associated with the 
user, client computing device 120, and/or medical device 
130 authenticated in step 306. In this manner, the sever 
computing device 110 maintains historic measurement data 
for an authenticated user, client computing device 120, 
and/or medical device 130. In response to a request received 
from the client computing device 120, the server computing 
device 110 at later date retrieves and/or analyzes the historic 
data for the authenticated user, the client computing device 
120, and/or the medical device 130. Further, the server 
computing device 110 provides the client computing device 
120 with results data in the form of a HTML document that 
includes tables, charts, graphs, explanations, etc. to aid in 
assessing the meaning of the current measurement data 
and/or the historic measurement data. 

[0077] Alternatively, the server computing device 110 
simply analyzes the received measurement data and pro- 
vides the client computing device 120 with results data that 
is representative of such analysis without storing the mea- 
surement data for future retrieval and analysis. In this 
manner, the server computing device 110 provides a user an 
anonymous mechanism for analyzing their current measure- 
ment data. 



[0078] A flowchart depicting another exemplary method 
of operation 400 is illustrated in FIG, 4. As illustrated, the 
exemplary, method 400 begins in step 402 with establishing 
a physical communications link 140 between the client 
computing device 120 and the medical device 130 as 
described above in regard to FIG. 3. 

[0079] In step 404, the client computing device 120 estab- 
lishes communications with the server computing device 
U0. In an exemplary embodiment, the client computing 
device 120 establishes communications with the server 
computing device 110 in response to a user requesting via 
the user interface 210 that the client transport agent 212 
establish communications with the server computing device 
110. In particular, the user in the exemplary embodiment 
requests via a web browser of the user interface 210 that the 
web browser connect to a particular server computing device 
110 and associated transport agent 202 identified by a 
particular WKl (Universal Resource Identifier), URL (Uni- 
versal Resource Locator), PURL (Persistent Uniform 
Resource Locator) and/or URN (Universal Resource Name) 
which services medical devices 130 of a particular family or 
type. By utilizing different URLs for different models of 
medical devices 130, different types of medical devices 130, 
different classes of medical devices 130, and/or different 
manufacturers of medical devices 130, the URL essentially 
provides a mechanism to identify or partially identify the 
medical device 130 attached to the cb'ent computer system 
120. For example, a first URL may be defined for a first 
model of glucose meters, a second URL may be defined for 
a class of glucose meters which have similar capabilities, 
and a third URL may be defined for all cholesterol meters of 
a certain manufacturer. 

[0080] The server computing device 110 in step 406 
attempts to authenticate the user, the client computing 
device 120, and/or the medical device 130 in a manner 
similar to step 306 of FIG. 3. In step 408, the server 
computing device 10 determines whether the attempt to 
authenticate the user, the client computing device 120, 
and/or the medical device 130 succeeded in a manner similar 
to step 308 of FIG. 3. In, step 410, the server computing 
device 110 performs various other actions in response to 
receiving an invalid username/password pair such as logging 
the invalid username/password pair, logging the network 
address of the client computing device 120, blocking con- 
nections from the client computing device 120 if a threshold 
number of attempts is exceeded, etc and returns to step 406 
in order to re -attempt to authenticate the user, the client 
computing device 120, and/or the medical device 130. 

[0081] In step 412, the client computing device 120 pro- 
vides the server computing device 110 with information 
from which the server computing device 110 may determine 
whether the client computing device 120 has an appropriate 
device identification component 214 for the medical device 
130. For example, the client computing device 120 may 
provide the server computing device 110 with a version 
number, filename, byte length, checksum value, or other 
information about the current device identification compo- 
nent 214 (if any) of the cb'ent computer device 120. 

[0082] From the information received from the client 
computing device 120 and data maintained by the server 
computing device 110, the server computing device 110 in 
step 414 determines whether to transfer an identification 
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compoDeDt 214 to the client computing device 120. In an 
exemplary embodiment, the server computing device 110 
determines that an identification component 213 needs to be 
transferred to the client computing device 120 if the client 
computing device 120 does not have an identification com- 
ponent 214 for the type of medical device 130 attached to the 
client computing device 110, or if the identification compo- 
nent 214 of the client computing device 120 is not the latest 
version of the identification component 214 for the type of 
medical device 130 attached to the client computing device 
120. 

[0083] As described above in regard to steps 412 and 414, 
the client computing device 120 essentially provides the 
server computing device 10 with information from which 
the server computing device . 110 determines the appropri- 
ateness of the identification component 214 of the client 
computing device 120. However, it should be appreciated 
that alternatively the server computing device 110 may 
provide the client computing device 120 with information 
from which the client computing device 120 determines for 
itself the appropriateness of the identification component 
214 of the client computing device 120. In particular, the 
client computing device 120 may determine whether the 
identification component 214 of the client computing device 
120 needs to be updated in a manner similar to steps 316 and 
318 of FIG. 3. 

[0084] If the server computing device 110 determines an 
identification component 214 is to be transferred to the client 
computing device 120, then the server computing device 110 
in step 416 causes the identification component 214 to be 
transferred to the client computing device 120. As should be 
appreciated, the server computing device 110 utilizes vari- 
ous data transfer techniques to transfer the identification 
component 214 to the client computing device 120 such as 
FTP transfer, HTTP transfer, remote copy, etc. In particular, 
the server computing device 110 in an exemplary embodi- 
ment provides the web browser of the user interface 210 
with an HTML document which when processed by the web 
browser causes the client computing device 120 to download 
and execute the identification component 214 from the 
server computing device U0 or another computing device. 

[0085] In step 418, the client computing device 120 pro- 
vides the server computing device 110 with device infor- 
mation from which the server computing device 110 deter- 
mines the proper protocol component 204 to be used with 
the medical device 130. As indicated above, the device 
identification component 214 interrogates the medical 
device 130 via a series of signals, receives signals from the 
medical device 130 in response to the interrogation, and 
discerns the type of medical device 130 connected to the 
client computing device 120 based upon the signals received 
from the medical device 130. The signals received from the 
medical device 130 include ACK signals and/or other sig- 
nals that are indicative of information such as a serial 
number, model number, device type, version number, etc. At 
any rate, the device identification component 214 provides 
the server computing device 110 with device information via 
the client transport agent 212 from which the server com- 
puting device 110 ascertains the type of medical device 130 
opcrably coupled to the client computing device 120. 

[0086] The server computing device 110 then determines 
in step 414 the proper protocol component 204 to commu- 



nicate with the identified medical device 130. In step 416, 
the server computing device 110 causes the proper protocol 
component 204 to be used with the identified medical device 
130 to be transferred to the client computing device 120. To 
this end, the server computing device 110 provides the client 
computing device 120 with a location from which the client 
computing device 120 downloads the proper protocol com- 
ponent 204. However, it should be appreciated that instead 
of the client computing device 120 downloading the infor- 
mation from the location identified by the server computing 
device 204, the server computing device 110 could alterna- 
tively upload the protocol component 204 to the client 
computing device 120 or causing another computing device 
to upload the protocol component 204 to the client comput- 
ing device 120. 

[0087] The client computing device 120 then in step 424 
executes the proper protocol component 204 in order to 
transfer data and/or control information between the client 
computing device 120 and the medical device 130. As a 
result of executing the proper protocol component 204, the 
client computing device 120 performs various operations in 
regard to communicating with the medical device 130 on the 
behalf of the client computing device 120 and/or the server 
computing device 110. For example, the server computing 
device 110 may cause client computing device 120 to issue 
commands to the medical device 130 via the protocol 
component 204 which cause the medical device 130 to 
adjust an internal clock, clear stored measurement data, 
retrieve stored measurement data, update calibration or other 
parameters used to obtain measurement data, perform a test 
to obtain measurement data, or other tasks. 

[0088] Similarly, the server computing device 110 may 
cause the client computing device 120 to transfer measure- 
ment data, device status data, etc. from the medical device 
130 to the server computing device 110. Accordingly, the 
server computing device 110 in step 426 processes data 
received from the measurement device 130 via the client 
computing device 120 in a manner similar to step 324 of 
FIG. 3. 

[0089] A flowchart depicting yet another exemplary 
method of operation 500 is illustrated in FIG. 5. As illus- 
trated, the exemplary method 400 begins in step 502 with 
establishing a physical communications link 140 between 
the client computing device 120 and the medical device 130 
as described above in regard to FIG. 3. 

[0090] In step 504, the client computing device 120 estab- 
lishes communications with the server computing device 
110. In an exemplary embodiment, the client computing 
device 120 establishes communications with the server 
computing device 10 in response to a user requesting via the 
user interface 210 that the client transport agent 212 estab- 
lish communications with the server computing device 110. 
In particular, the user in the exemplary embodiment requests 
via a web browser of the user interface 210 that the web 
browser connect to a particular server computing device 110 
and associated transport agent 202 identified by a particular 
URI (Universal Resource Identifier), URL (Universal 
Resource Locator), PURL (Persistent Uniform Resource 
Locator) and/or URN (Universal Resource Name) which 
services medical devices 130 of a particular model, class, 
and/or manufacturer. By utilizing different URLs for differ- 
ent models, different types, different classes, and/or different 
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manufacturers of medical devices 130, the URL essentially 
provides a mechanism to identify or partially identify the 
medical device 130 attached to the client computer system 
120. For example, a first URL may be defined for a first 
model of glucose meters, a second URL may be defined for 
a class of glucose meters which have similar capabilities, 
and a third URL may be defined for all cholesterol meters of 
a certain manufacturer. 

[0091] la an exemplary embodiment, the client computing 
device 120 in step 504 provides the user of toe medical 
device 130 with a list of medical device from which to select 
the model, type, class, and/or manufacturer of the medical 
device 130 coupled to the client computing device 120. In 
the exemplary embodiment, the list of medical devices 130 
is defined by a HTML document comprising hyper-links 
which when selected cause the client computing device 120 
to establish communications with the server computing 
device 110 via the proper network location (e.g. URL) for 
the medical device 130. The list of medical devices 130 may 
alternatively or in addition to be presented as one or more 
drop-down lists from which the user may select the model, 
type, class, and/or manufacturer of the medical device 130. 
Furthermore, the list of medical devices 130 may be pre- 
sented to the user via an application program that enables the 
user to select the model, type, class, and/or manufacturer of 
the medical device 130 via drop-down lists, check-boxes, 
radio-buttons, text entry forms, and/or other data input 
mechanisms and that determines the proper oetwork location 
(e.g. URL) from the received information. 

[0092] In step 506, , the server computing device 110 
causes the proper protocol component 204 to be used with 
the identified medical device 130 to be transferred to the 
client computing device 120. It should be appreciated that 
the client computing device 120 has essentially identified the 
model, type, class, and/or manufacturer of the medical 
device 130 in step 504 via the particular URI, URL, PURL, 
and/or URN. Accordingly, the server computing device U0 
as a result of establishing communications with the client 
computing device 120 via the URI, URL, PURL, and/or 
URN provides the client computing device 120 with a 
location from which the client computing device 120 down- 
loads the protocol component 204 for the model, type, class, 
and/or manufacturer of the medical device 130. However, it 
should be appreciated that instead of the client computing 
device 120 downloading the information from the location 
identified by the server computing device 204, the server 
computing device 110 could alternatively upload the proto- 
col component 204 to the client computing device 120 or 
cause another computing device to upload the protocol 
component 204 to the client computing device 120. 

[0093] The client computing device 120 then in step 508 
executes the proper protocol component 204 in order to 
transfer data and/or control information between the client 
computing device 120 and the medical device 130. As a 
result of executing the proper protocol component 204, the 
client computing device 120 performs various operations in 
regard to communicating with the medical device 130 on the 
behalf of the client computing device 120 and/or the server 
computing device 110. For example, the server computing 
device 110 may cause cheat computing device 120 to issue 
commands to the medical device 130 via the protocol 
component 204 which cause the medical device 130 to 
adjust an internal clock, clear stored measurement data, 



retrieve stored measurement data, update calibration or other 
parameters used to obtain measurement data, perform a test 
to obtain measurement data, or other tasks. 

[0094] Similarly, the server computing device 110 may 
cause the client computing device 120 to transfer measure- 
ment data, device status data, etc. from the medical device 
130 to the server computing device 110. Accordingly, the 
server computing device 110 in step 510 processes data 
received from the measurement device 130 via the client 
computing device 120 in a manner similar to step 324 of 
FIG. 3. 

[0095] While the invention has been illustrated and 
described in detail in the drawings and foregoing descrip- 
tion, such illustration and description is to be considered as 
exemplary and not restrictive in character, it being under- 
stood that only exemplary embodiments have been shown 
and described and that all changes and modifications that 
come within the spirit of the invention are desired to be 
protected. For example, exemplary methods of operation 
have been described as a series of sequential steps. However, 
it should be appreciated that certain steps of the exemplary 
methods of operation may occur in parallel or pseudo- 
parallel. Moreover, it should be appreciated that the order of 
steps is merely exemplary and embodiments of the invention 
may execute steps in a different order than the ones depicted. 
Furthermore, it should be appreciated that embodiments of 
the invention may combine steps from one or more of the 
exemplary methods depicted in FIGS. 3-5 and that embodi- 
ments, of the invention are not required to include all of the 
steps of one of the exemplary methods depicted in FIGS. 
3-5.' .>'•__ , 

What is claimed is: 

1. A method for accessing a medical device operably 
coupled to a computing device, the method comprising the 
steps of: 

receiving identification information from the computing 
device that is indicative of a medical device type; 

transferring a protocol component to the computing 
device based upon the identification information; and 

receiving measurement data from the medical device in 
response to the computing device communicating with 
the medical device via the protocol component. 

2. The method of claim 1, further comprising the steps of: 

receiving authentication information from the computing 
device; and 

associating the measurement data received from the medi- 
cal device with previously received data associated 
with the authentication information. 

3. The method of claim 1, further comprising the steps of: 

analyzing the measurement data received from the medi- 
cal device to obtain results data; and 

providing the computing device with the results data. 

4. The method of claim 1, further comprising the steps of: 

receiving authentication information from the computing 
device; 

associating the measurement data received from the medi- 
cal device with previously received measurement data 
associated with the authentication information; 
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analyzing the measurement data and the previously 
received measurement data associated with the authen- 
tication information to obtain results data; and 

providing the computing device with the results data. 

5. The method of claim 1, further comprising the steps of: 

receiving authentication information comprising a user 
name and a password; 

verifying thai the password is correct for the user name; 
and 

associating the measurement data received during the 
receiving step with any previously received measure- 
ment data associated with the user name if the pass- 
word is correct. 

6. The method of claim 1, wherein the transferring step 
comprises the step of: 

transferring the protocol component to the computing 
device in accordance with the Hyper-Text Transport 
Protocol (HTTP). 

7. The method of claim 1, further comprising the steps of: 

analyzing the measurement data received from the medi- 
cal device to obtain results data in a markup language 
format; and 

providing the computing device with the results data in 
the markup language format. 

8. The method of claim 1, further comprising the step of: 

selecting the protocol component from a plurality of 
protocol components based upon the identification 
information and device data correlating medical device 
types with the plurality of protocol components. 

9. The method of claim 1, further comprising the step of: 

selecting the protocol component from a plurality of 
protocol components that defines at least one of: a 
message format, 

a packet formal, 

a transfer rate, 

an error detection scheme, 

an error correction scheme, 

a command set, 

a compression scheme 

for transferring information to and from the medical 
device. 

10. The method of claim 1, wherein the step of receiving 
measurement data comprises the step of: 

receiving measurement data indicative of at least one 
blood glucose measurement. 

11. The method of claim 1, further comprising the step of 

receiving medical device configuration information from 
the medical device in response to the computing device 
communicating with the medical device via the proto- 
col component. 

12. The method of claim 1, further comprising the step of 

causing the computing device to transfer medical device 
configuration information to the medical device via the 
protocol component. 



13. The method of claim 1, further comprising the step of 

transferring a identification component to the client com- 
puting device that causes the client computing device to 
interrogate the medical device and provide the identi- 
fication information. 

14. A method of accessing a medical device operably 
coupled to a computing device, the method comprising the 
steps of: ! ' 

receiving identification information from the computing 
device indicative of a medical device type of the 
medical device; 

providing the computing device with protocol component 
information which identifies a protocol component for 
the computing device to use to communicate with the 
medical device from a plurality of protocol compo- 
nents; and 

receivingdata from the medical device in response to the 
computing device communicating with medical device 
via the protocol component identified by the protocol 
component information. 

15. The method of claim 14, further comprising the steps 

of: 

transferring the protocol component identified by the 
protocol component information to the computing 
device prior to the receiving step. 

16. The method of claim 14, further comprising the steps 

<*'- .' < 

transferring the protocol component identified by the 
protocol component information to the computing 
device if the computing device does not have a copy of 
the identified protocol component. 

17. The method of claim 14, further comprising the steps 
of: ' 

receiving authentication information from the computing 
device; 

associating the data received from the medical device 
with previously received data associated with the 
authentication information. 

18. The method of claim 14, wherein the transferring step 
comprises the step of: 

transferring the protocol component to the computing 
device in accordance with the Hyper-Text Transport 
Protocol (HTTP). 

19. The method of claim 14, wherein the step of receiving 
data comprises the step of: 

receiving measurement data indicative of at least one 
blood glucose measurement. 

20. The method of claim 14, wherein the step of receiving 
data comprises the step of: 

transferring a identification component to the client com- 
puting device that causes the client computing device to 
interrogate the medical device and provide the identi- 
fication information. 

21. A method of providing a computing device with 
access to a medical device, the method comprising the steps 
of: 

providing the computing device with identification infor- 
mation from which a protocol component for use with 
the medical device is determined; 
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receiving the proper protocol component from the com- 
puting device in response to providing the computing 
device with the identification information; and 

communicating with the medical device via the proper 
protocol component. 

22. The method of claim 21, further comprising the steps 
of: 

transferring to the computing device data obtained from 
the medical device during the communicating step; and 

receiving from the computing device results data that is 
based upon the data obtained from the medical device. 

23. The method of claim 21, further comprising the steps 
of: 

transferring to the computing device data obtained from 
the medical device during the communicating step; 

providing the computing device with authentication infor- 
mation; and 

receiving results data from the computing device that is 
based upon the data obtained from the medical device 
and any previously received data associated with the 
authentication information. 

24. The method of claim 21, further comprising the steps 
of: 

transferring to the computing device measurement data 
obtained from the medical device during the commu- 
nicating step, the measurement data indicative of at 
least one blood glucose measurement. 

25. The method of claim 21, further comprising the steps 
of: V 

transferring to the computing device data obtained from 
the medical device during the communicating step; 

providing the computing device with authentication infor- 
mation; 

receiving from the computing device in a markup lan- 
guage format results data that is based upon the data 
obtained from the medical device and previously 
received data associated with the authentication infor- 
mation; and 

displaying the results data via a user interface designed to 
display information in the markup language format 

26. The method of claim 21, wherein the receiving step 
comprises the step of: 

receiving the protocol component in accordance with the 
Hyper-Text Transport Protocol (HTTP). 

27. The method of claim 21, further comprising the step 

of: 

receiving a device identification component via which the 
identification information is obtained. 

28. A method of providing a computing device with 
access to a medical device, the method comprising the steps 
of: 

establishing communication with the computing device 
via a network address associated with the medical 
device; 

receiving protocol component information from the com- 
puting device which identifies the protocol component 



to communicate with the medical device from a plu- 
rality of protocol components; and 

communicating with medical device via the protocol 
component identified by the protocol component infor- 
mation. 

29. The method of claim 28, further comprising the steps 
of: 

receiving the protocol component identified by the pro- 
tocol component information from the computing 
device prior to the communicating step. 

30. The method of claim 29, wherein the receiving step 
comprises the step of: 

receiving the protocol component in accordance with the 
Hyper-Text Transport Protocol (HTTP). 

31. The method of claim 28, further comprising the steps 
of: 

receiving the protocol component identified by the pro- 
tocol component information from the computing 
device if a copy of the protocol component identified 
by the protocol component information is not already 
available. 

32. The method of claim 28, further comprising the steps 
of: 

transferring data obtained from the medical device in 
response to the communicating step to the computing 
device. 

33. The method of claim 28, further comprising the steps 
of: 

transferring data obtained from the medical device in 
response to the communicating step to the computing 
device; 

providing the computing device with authentication infor- 
mation; 

receiving from the computing device in a markup lan- 
guage format results data that is based upon the data 
obtained from the medical device and previously 
received data associated with the authentication infor- 
mation; and 

displaying the results data via a user interface designed to 
display information in the markup language format 

34. The method of claim 28, further comprising the step 
of: 

transferring data to the computing device that is indicative 
of at least one blood glucose measurement. 

35. A first computing device for accessing a medical 
device operably coupled to a second computing device via 
a network, the first computing device comprising: 

a storage device comprising a plurality of protocol com- 
ponents that configure second computing device to 
communicate with a plurality of medical devices in 
accordance with a plurality of communications proto- 
cols supported by the plurality of medical devices; 

a transport agent operably coupled to the storage device 
and the network, the transport agent being adapted to 
receive from the second computing device identifica- 
tion information associated with a particular medical 
device operably coupled to the second computing 
device, to select from the plurality of protocol compo- 
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□eats of tbe storage device a protocol component to 
configure tbe second computing device for communi- 
cations with the particular medical device, and transfer 
to tbe second computing device via the network tbe 
protocol component selected from the plurality of pro- 
tocol components. 

36. The first computing device of claim 35, wherein the 
transport agent is further operable to receive measurement 
data from the medical device via the network in response to 
the second computing device communicating with medical 
device via tbe protocol component 

37. The first computing device of claim 35, wherein the 
transport agent is further adapted to receive measurement 
data from the medical device via the network in response to 
tbe second computing device communicating with medical 
device via the protocol component, to receive authentication 
information from the second computing device via tbe 
network, and to store tbe measurement data in tbe storage 
device such that the measurement data and any previously 
received measurement data may be received from the stor- 
age device based upon the authentication information. 

38. The first computing device of claim 35, wherein the 
transport agent is adapted to transfer the protocol component 
to the second computing device via the network in accor- 
dance with the Hyper-Text Transport Protocol (HTTP). 

39. The first computing device of claim 35^ wherein 

the storage device further comprises device data that 
correlates a plurality of medical device types with the 
plurality of protocol components, and 

the transport agent is further adapted to select the protocol 
component from tbe plurality of protocol components 
based upon the identification ■' information and the 
device data. 

40. The first computing device of claim 35, wherein the 
transport component selects the protocol component from 
the plurality of protocol components that defines at least one 
of: 

a message format, 

a packet format, 

a transfer rate, 

an error detection scheme, 

an error correction scheme, 

a command set, 

a compression scheme 

for transferring inform a lion to and from tbe medical 
device. 

41. A first computing device for accessing a medical 
device operably coupled to a second computing device via 
a network, the first computing device comprising: 

a storage device comprising a plurality of protocol com- 
ponents that configure the second computing device to 
communicate with a plurality of medical devices in 
accordance with communications protocols supported 
by the plurality of medical devices; 

a memory comprising a plurality of instructions; 

a network interface adapted to communicate with the 
second computing device via the network; and 



a processor operably coupled to tbe storage device, the 
memory, and tbe network interface and adapted to 
execute the plurality of instructions to cause the pro- 
cessor / 

to receive from the second computing device via the 
network interface identification information from 
which a medical device type of tbe medical device 
coupled to the second computing device is deter- 
mined, 

to provide protocol component information to the sec- 
ond computing device via tbe network interface 
which identifies the protocol component from the 
plurality of protocol components for the second 
computing device to use to communicate with the 
medical device, and 

to receive measurement data from the medical device 
via jtiit network interface in response to the second 
computing device communicating with medical 
device via the protocol component identified by tbe 
protocol component information. 

42. The first computing device of claim 41, wherein the 
plurality of instructions, when executed by the processor, 
further causes tbe processor to 

transfer the protocol component identified by the protocol 
component information to the second computing 
device via the network interface prior to receiving tbe 

■ measurement/data. 

43. Tbe first computing device of claim 41; wherein the 
plurality of instructions, when executed by the processor, 
further causes the processor to , 

transfer to tbe second computing device via tbe network 
interface, the protocol component identified by the 
protocol component information if the second comput- 
ing device does not have a copy of the protocol 
component identified by the protocol component infor- 
mation. 

44. The first computing device of claim 41, wherein the 
plurality of instructions, when executed by the processor, 
further causes tbe processor to 

receive authentication information from the second com- 
puting device via the network interface, and 

store tbe measurement data received from the medical 
device in the storage device such that the measurement 
data is associated with any previously received data 
associated with the authentication information. 

45. The first computing device of claim 41, wherein the 
plurality of instructions, when executed by the processor, 

. further causes tbe processor to 

analyze the measurement data received from tbe medical 
device to obtain results data in a markup language 
format, and 

provide the second computing device via tbe network 
interface with tbe results data in tbe markup language 
format. 

46. The first computing device of claim 41, wherein the 
plurality of instructions, when executed by the processor, 
further causes tbe processor to 

receiving measurement data from the medical device via 
the network interface that is indicative of at least one 
blood glucose measurement. 
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47. A first computing device for providing a second 
computing device with access to a medical device via a 
network, the first computing device comprising: 

a memory comprising a plurality of instructions; 

a network interface adapted to communicate with the 
second computing device via the network; 

a medical device interface adapted to establish a commu- 
nications link with tbe medical device; and 

a processor operably coupled to the memory, the network 
interface, and the medical device interface and adapted 
to execute the plurality of instructions to cause the 
processor 

to provide to the second computing device via the 
network interface identification information from 
which a protocol component for use with tbe medical 
device is determined; 

to receive the protocol component from the second 
computing device via the network interface in 
response to providing the second computing device 
with the identification information; 

to execute instructions of the protocol component to 
obtain measurement data from the medical device 
via tbe medical device interface; and 

transfer to the second computing device via the net- 
work interface, the measurement data obtained from 
tbe medical device. 

48. The first computing device of claim 47, wherein tbe 
plurality of instructions, when executed by the processor, 
further causes the processor to 

receive results data from the second computing device 
that is based upon the measurement data. 

49. Tbe first computing device of claim 48, further 
comprising a user interface adapted to present information in 
the markup language format, wherein the plurality of 
instructions, when executed by tbe processor, further causes 
the processor to 

provide authentication information to second computing 
device via tbe network interface, 

receive from the second computing device via the net- 
work interface, results data in a markup language 
format that is based upon the measurement data and 
previously received measurement data associated with 
the authentication information, and 

display the results data via tbe user interface. 

50. A first computing device for providing a second 
computing device with access to a medical device via a 
network, tbe first computing device comprising: 

a transport agent adapted to provide the second computing 
device with identification information from which a 
protocol component from a plurality of protocol com- 
ponents for communicating with the medical device is 
determined, and to receive from the second computing 
device protocol component information which identi- 
fies tbe protocol component of to communicate with the 
medical device; and 

an update component in communication with the transport 
agent, the update component adapted to receive the 



protocol component information, and to obtain from 
the second computing device the protocol component 
identified by tbe protocol component information. 

51. The first computing device of claim 50, further ' 
comprising a storage device, wherein tbe update component 
is further adapted to determine whether the storage device 
includes tbe protocol component identified by tbe protocol 
component information, and to obtain the protocol compo- 
nent from the second computing device only if the storage 
device does not include tbe protocol component. 

52. The first computing device of claim 50, wherein tbe 
transport component is further adapted to communicate with 
the medical device via the protocol component, to transfer 
data obtained from the medical device to tbe second com- 
puting device via tbe network measurement, to provide 
authentication information to tbe second computing device 
via the network, and to receive results data from the second 
computing device via the network, the results data being 
based upon tbe measurement data and previously received 
measurement data associated with the authentication infor- 
mation. 

53. The first computing device of claim 50, further 
comprising a user interface designed to display information 
in tbe markup language format, wherein the transport com- 
ponent is further adapted to communicate with the medical 
device via tbe protocol component, transfer to tbe second 
computing device via the network measurement data 
obtained from the medical device, provide authentication 
information to tbe second computing device via tbe network, 
receive from the second computing device via the network 
results data in a markup language format that is based upon 
the measurement data and previously received measurement 
data associated with the authentication information, and 
display the results data via the user interface. 

54. A first computing device for providing a second 
computing device with access to a medical device via a 
network, tbe first computing device comprising: 

a storage device; 

memory comprising a plurality of instructions that define 
a web browser; 

a network interface adapted to communicate with the 
second computing device via the network; 

a medical device interface adapted to establish a commu- 
nications link with the medical device; and 

a processor operably coupled to tbe storage device, the 
network interface, and the memory and adapted to 
execute the plurality of instructions of the memory to 
cause the processor 

to provide identification information to tbe second 
computing device via tbe network interface from 
which a protocol component for communicating 
with the medical device is determined, 

to receive protocol component information from the 
second computing device via the network interface 
which identifies the protocol component that should 
be used to communicate with tbe medical device, 

determine whether the storage device includes tbe 
protocol component identified by the protocol com- 
ponent information, and 
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obtain the protocol component from the second com- 
puting device via the network interface if the storage 
device does not include the protocol component 
identified by the protocol component information. 
55. A system for providing access to a medical device, the 
system comprising: 

a first computing device; 

a second computing device in communication with the 
first computing device, the second computing device 
being adapted to obtain identification information from 
the medical device, to transfer the identification infor- 
mation to the first computing device, tb receive proto- 
col component information from the first computing 
device that identifies a protocol component to be used 
by the second computing device to communicate with 
the medical device, to determine whether the second 
computing device already has the protocol component 
identified by the protocol component information, and 
obtain the protocol component identified by the proto- 
col component information from the first computing 
device if the second computing device does not already 
have the protocol component identified by the protocol 
component information, and wherein ■ 



the first computing device is adapted to receive the 
identification information from the second comput- 
ing device, to identify the protocol component of. a 
plurality of protocol components, to transfer the 
protocol component information to the second com- 
puting device, and to transfer the protocol compo- 
nent to the second computing device if the second 
computing device does not already have the protocol 
component identified by the protocol component 
information. 
56. The system of claim 55, wherein 
the first computing device is further adapted to request the 
second computing device to obtain measurement data 
from the medical device and to transfer the measure- 
ment data obtained from the medical device to the first 
computing device, and 
the second computing device is further adapted to obtain 
the measurement data from the medical device via the 
protocol component identified by the protocol compo- 
nent information and to transfer the measurement data 
to the first computing device in response to receiving 
the request from the first computing device. 
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